Use of communications networks such as the Internet to access secure services such as customer bank account details is now commonplace. However, it is important for the user that this type of access cannot be compromised by a malicious third party.
Transport Layer Security (TLS) and its predecessor Secure Sockets Layer (SSL) are commonly used protocols to enable information to be sent securely over the communication network. These protocols rely on authentication of a certificate to allow each party to authenticate themselves to other parties. Certificates are provided by a Certifying Authority (CA).
Consider the situation in which a user client accesses a secure server to, for example, access a users bank account. When the user client accesses the server, the server presents its certificate to the user client. The user client validates the server's certificate. Note that if the user client is to be sure that the certificate comes from the same server, information identifying the server (such as a URL) should be included in the certificate. Only a trusted CA can include such information in the certificate, and so checking the information identifying the server against information identifying the server included in the certificate can be used by the client to identify that the certificate belongs to the server.
It is possible for a malicious third party to approach a CA claiming to represent someone else, and obtain a certificate. For example, a malicious third party in Brazil may approach a CA based in the UK, and claim to represent a Finnish bank. The malicious third party would present his own identifying information to be embedded in the certificate. The CA may not have the resources to perform comprehensive checks on the third party and simply issue a certificate on the basis of cursory checks. For example, the third party may obtain remote access to the Finnish bank's computer network and send an email to the CA that seems to come from an employee of the Finnish bank. There are several ways in which a malicious third party can trick a CA into issuing a certificate. The certificate obtained by the third party would therefore appear to be linked to the identification of a server of the Finnish bank when it in fact is linked to an identification of a server used by the third party.
Once a malicious third party has obtained a certificate, any communications between a client and the Finnish bank server become vulnerable to a so-called “man-in-the-middle” attack. In this type of attack, the malicious third party is an attacker and connects to both the client and to the server, as illustrated in FIG. 1. The attacker 1 impersonates the server 2 towards the client 3, and impersonates the client 3 towards the server 2, making the client 3 and sever 2 believe that they are communicating directly with one another. Even when the attacker 1 has obtained a certificate that incorporates identifying information the Server 2, the user's client 3 can be fooled into thinking that it is communicating with the Server 2 rather than the attacker 1.
Further problems may arise when a malicious third party is able to create server certificates that are issued by a root CA or its delegate CA. For example, the malicious third party end-point may perform a man-in-the-middle attack between an end-point and the CA.
Certificate pining is an emerging method to circumvent valid certificate based attacks. However, this is not effective if the first session is targeted with a man-in-the-middle attack. Also this does not provide more granular control to trust of certificates.
Revocation lists of revoked certificates can also be ineffective as they are usually not turned on, and would not help in the case of a valid certificate chain from a trusted root and the trusted root has not acknowledged the false certificate in its revocation list.
Using a centralized “many eyes” strategy where certificates are retrieved by several clients and compared at the backend server can be problematic, since an attacker may be able to prevent access to the central backend and thus users cannot distinguish between network or backend server error and the attacker manipulating the network traffic.
There remains a need for a certificate trustworthiness evaluation system that does not rely solely on central servers.